From: Joey Hess Date: Thu, 4 Sep 2025 18:46:44 +0000 (-0400) Subject: analysis X-Git-Tag: archive/raspbian/10.20251029-1+rpi1~1^2~3^2~152 X-Git-Url: https://dgit.raspbian.org/%22http://www.example.com/cgi/%22/%22http:/www.example.com/cgi/%22?a=commitdiff_plain;h=e1dcf98b7850d50cfb5355fc8a510c319aaba3b2;p=git-annex.git analysis --- diff --git a/doc/bugs/35_failed_tests_on_beegfs/comment_5_ea2368e228753931099084e634c7bbca._comment b/doc/bugs/35_failed_tests_on_beegfs/comment_5_ea2368e228753931099084e634c7bbca._comment index 47ad7d8ff9..c2353a4f68 100644 --- a/doc/bugs/35_failed_tests_on_beegfs/comment_5_ea2368e228753931099084e634c7bbca._comment +++ b/doc/bugs/35_failed_tests_on_beegfs/comment_5_ea2368e228753931099084e634c7bbca._comment @@ -59,9 +59,7 @@ a simpler program: So, really supporting this would mean auditing every file git-annex opens with openFile to see if the handle is ever passed to a child process, -and otherwise making it use CloseOnExec. Probably openFile is never actually used to -send a handle to a child process, so a version that just sets CloseOnExec could be -written and switched to. +and otherwise making it use CloseOnExec. I don't care a great deal about supporting Beegfs; it would be nice to support it in some of its less crazy configurations if possible. But not leaking FDs diff --git a/doc/bugs/35_failed_tests_on_beegfs/comment_6_172a92bf49be25355dda3f88b377a6f4._comment b/doc/bugs/35_failed_tests_on_beegfs/comment_6_172a92bf49be25355dda3f88b377a6f4._comment new file mode 100644 index 0000000000..4d33caa11d --- /dev/null +++ b/doc/bugs/35_failed_tests_on_beegfs/comment_6_172a92bf49be25355dda3f88b377a6f4._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2025-09-04T18:24:33Z" + content=""" +Note that `openFile` is not the only one that would need to be dealt with. +Also `withFile`, `openBinaryFile`, and `withBinaryFile`. + +And, since none of those provide a way to set CloseOnExec, they would have +to be changed to use `openFd` with CloseOnExec, and then mkHandleFromFD. + +I have checked and none of those are ever used to create a handle that is +intentionally passed to a child process. The only uses of `handleToFd` +result in a FD that gets dupped to another FD number, and dup() does not +inherit the close-on-exec flag. So it should be safe to just write new +versions of all of those. + +Also there are a few uses of `openFd` that don't set CloseOnExec. + +And possibly also some libraries might open files, I don't know. +"""]]